就讀碩士時，在拜讀《重構─改善既有程式的設計》後，就熱衷於重構相關議題。認為重構很治癒，把壞味道變成美好的架構是一門讓人陶醉的藝術，直到現在仍然如此。

但是在職場上，想要重構遇到的最大問題在於，對於 PM 或是客戶來說，重構是沒有價值的，至少他們很難感受到。儘管工程師希望能夠好好重構，為未來的開發與維護打好地基，但通常都沒有一個空下來的時間能夠滿足他們的奢望。

而對雙方最大的災難，就是為期好幾週的純重構工作進度。身為開發者很難有把握在這種時候只重構一小部分，對其他壞味道視而不見。於是重構的成本大於規劃或預期，軟體開發的時程延宕，更可怕的是，軟體可能還在重構過程中不小心埋下缺陷、漏洞。這類事情的一再發生，拖垮了開發者的自信、動力，擊潰了主管、客戶對於工程的信任。

但是因此放棄重構嗎？「不！」我想多數的開發者都很難接受。但要因此和主管或業主槓上嗎？這聽起來也不是好主意。那該怎麼辦呢？或許我們該理解重構的時機與配套的方法。

重構依照完成時間的成本來分類主要有分兩種，一種是順手可以完成的，一種是需要一個不短的開發時段去完成的。

通常前者是可以在開發功能或修復缺陷時，順手完成。但是若遇到後者的情況，會建議先記錄在一個團隊都看得到的清單（可能是技術債清單、或是壞味道清單），並在每次規劃進度時，也挑一到數個（團隊與主管或客戶雙方都能接受的範圍）希望重構的項目，一起列入開發成本或待辦清單，透過這種方式逐步改善。

另外有一種例外是，這個專案是免洗專案，沒有要長期維護的打算，且沒有要重用裡面的程式碼，亦即重構不會對未來有太大幫助時，這時最好的作法就是忍痛不重構。

掌握重構時機，避免陷入重構的泥沼，保持「持續創造價值與改善程式碼」的平衡，我想就是今天我想要分享的。

當然，重構對象盡量要先有測試，避免重構時改變了既有的功能這件事也很重要，但和本文主旨無關，就不詳述了。